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Abstract 

Oblivious RAM simulation is a method for achieving confidentiality and privacy in cloud computing 
environments. It involves obscuring the access patterns to a remote storage so that the manager of that 
storage cannot infer information about its contents. Existing solutions typically involve small amortized 
overheads for achieving this goal, but nevertheless involve potentially huge variations in access times, 
depending on when they occur In this paper, we show how to de-amortize oblivious RAM simulations, 
so that each access takes a worst-case bounded amount of time. 

1 Introduction 

In the cloud storage model, a user, Alice, remotely stores a large set of data with a remote server. Bob, 
offloading her need to maintain her data. To achieve confidentiality from Bob, Alice should store her data in 
encrypted form, but encryption alone is not enough, since information about her data may be leaked by the 
pattern in which she accesses it. 

Oblivious RAM simulation tackles this privacy -protection problem by hiding data access patterns from 
Bob. Such solutions simulate a general random access machine (RAM) computation with respect to the 
external storage, but they perform additional obfuscating accesses that hide the locations of requests. Re- 
cently there has been a considerable amount of work on methods that optimize the access overhead, i.e., 
the number of additional accesses to the data repository per request to provide oblivious access (e.g., 
see [7, 6, 1, 12, 10, 2, 14, 5]). Nevertheless, existing oblivious RAM solutions still suffer from a worst-case 
access overhead that can be as bad as i7(n) for n data items. This worst-case overhead makes oblivious RAM 
unsuitable in many practical scenarios, such as real-time systems and multi-user systems. For example, 
consider a multi-user environment where a group of users share the same external storage: one of the users 
has to make $7(n) accesses in the worst case to make sure all accesses remain oblivious. And she may have 
to spend this much time with each of her accesses. Thus, we are interested in this paper of de-amortized 
solutions that have the same access overhead for every request. 



1.1 The Oblivious RAM Model 

An oblivious RAM (ORAM) is an interface between a client, Alice, and a data repository. Bob, whereby 
Alice outsources the storage of n data items to Bob. When Alice makes a request for item x, she issues a 
sequence of accesses to Bob's data repository to retrieve x in such a way that Bob is unable to determine 
which item is being accessed (any better than a random guess). Of course, there is a simple way for Alice 
to obfuscate her requests — she could simply read all items from the data repository with each request (her 



Table 1: Comparison of Oblivious RAM simulation Methods. 
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requested item x is sure to be in this collection). But such a solution has access overhead 0(n); hence is 
quite inefficient. 



1.2 Related Prior Work 

Prior work on oblivious RAM addresses the trade-off between the size of the client's memory, the access 
overhead, and the space overhead at the data repository, i.e., the additional space used beyond the n items. 
Based on the assumptions about the client, oblivious RAM models can be split into stateless and stateful 
solutions. A stateless oblivious RAM is not allowed to keep a state between requests and hence can be used 
in a multi-user scenario. Stateful solutions assume Alice keeps information in a private storage (which she 
maintains), which helps her perform her accesses obliviously in the remote storage. 

Stateless oblivious RAM simulation was first proposed by Goldreich and Ostrovsky in [5], who present 
a preliminary simple solution with 0{y/n\o^ n) amortized access overhead, referred as the square-root 
solution, and a more complex solution with O(log'^n) amortized access overhead. Goodrich and Mitzen- 
macher [6] improve this result by giving a method with O(log^n) amortized access overhead with high 
probability. Recently Kushilevitz et al. [10] show that techniques from [6] can be extended to obtain 
0(log^ n/ log log n) amortized access overhead. All the above methods are stateless and consider a private 
memory of size 0(1) for Alice, an overly restrictive assumption in practice. 

Other solutions [7, 13, 14] improve the overall access overhead by assuming that a client has a workspace 
of non-constant size. Williams and Sion [13] achieve 0(log^ n) expected amortized access overhead and 
0(n log n) space overhead with 0{y/n) private memory. Williams et al. [14] improve the method from 
[13] to achieve O(lognloglogn) amortized access overhead. Goodrich et al. [7] give an oblivious RAM 
simulation method with O(logn) amortized access overhead given that a client has access to workspace of 
size 0{n^), for a given constant u > Q. 

Other recent papers provide stateful solutions, i.e., where a client maintains a state between requests 
to the data repository in a non-constant sized private cache. A RAM simulation by Goodrich and Mitzen- 
macher [6] achieves an overhead of O(logn) and uses a private cache of size 0{n^), for any given fixed 
constant v > Q, which maintains a state. Boneh et al. [1] propose a scheme that achieves an amortized 
overhead of 0(1) but using a cache of size 0{yJn\ogn), which also maintains state. 

Damgard et al. [2] and Goodrich et al. [7] present stateless oblivious RAM simulations without crypto- 
graphic assumptions about the existence of random hash functions. Damgard et al. [2] show that amortized 
access overhead of 0(log^ n) is possible for oblivious RAM simulation without using random functions. 



Goodrich et al. [7] present a method with O(log^n) amortized access overhead that also does not use 
random functions. 

To sum up, then, all the methods described above have amortized access overheads. (See Table 1 for the 
comparison of ORAM simulations.) Indeed, even the most efficient previous solutions can incur an 0{n) 
overhead in the worst case for any given request. This is slightly improved in recent work by Stefanov et 
al. [12], who give an oblivious RAM simulation that achieves an 0{^/n) access overhead in the worst case, 
while having 0(log^ n) amortized overhead complexity; hence, their solution is also amortized, but not as 
inefficient as previous schemes on a per-access basis. 

Oblivious RAM simulation has also been used to protect against traffic analysis in a networked file 
system [15]. 

Kosaraju and Pop [9] give an overview of general de-amortization techniques. E.g., one of the tech- 
niques, de-amortization via data duplication [3], maintains two copies of the data set: one for performing 
the redistribution of the data and one for accesses. We cannot apply these general techniques to our problem, 
however, since we also need to ensure the obliviousness of the de-amortized algorithm. 

1.3 Our Results 

We present two oblivious RAM simulations that achieve a sublinear access overhead on every request made 
by the client to the data repository. The first is a de-amortized version of the square root solution originally 
presented in [5]. This method has 0{^/n\o^ n) access overhead in the worst case while using 0{n) space 
on the data repository and assuming 0(1) workspace on the client side. We then de-amortize an efficient 
oblivious RAM simulation by Goodrich et al. [7], that we refer to as the "logn hierarchical" solution. In 
this solution, we achieve wost-case access overhead of 0(log n) and space overhead of 0(n), assuming that 
a client has access to a workspace of size 0{'n7'), for any given fixed constant r > 0. 

2 Preliminaries 

We assume that the client outsources n data items to a remote data repository that supports the following 
access operations: 

• read{i): return the content of location i; 

• write{i, x): write data item x to location i; 

• copy{i, j, count): copy a memory block of size count from location i to location j. 

The latter block-copy operation is not actually required by our methods but using it makes the algorithms 
more intuitive. 

We also assume that provider of the storage service. Bob, is an honest-but-curious adversary [4], in that 
he correctly performs all operations and does not tamper with the data. 

A data item is stored by Alice in the repository as the encryption of a pair (x, v), where x is the virtual 
address of the item in the RAM and v is its value. Typically, oblivious RAM solutions use probabilistic 
encryption to make sure that Bob cannot distinguish between reads and writes or track repeated accesses 
to the same data item. Namely, Alice encrypts each data item that she writes to the data repository using a 
probabilistic encryption scheme based on her private key. Also, Alice reencrypts and rewrites each data item 
she accesses so that its encryption will change even if the data item is not modified. This technique ensures 
that Bob is computationally unable to determine the plaintext of any memory cell from that cell's contents 
alone. Also, it is unfeasible for Bob to determine whether two memory cells store encryptions of the same 
data item. 
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Figure 1 : Memory layout of the data repository during oblivious RAM simulation: (a) original version of 
the square-root solution [5]; (b) our de-amortized version (Section 3.1). 

2.1 Square-Root Solution 

We first give an overview of the square-root oblivious RAM simulation method [5], which has 0(y^log^ n) 
amortized access overhead. We give enough details about the method for a reader to understand our de- 
amortized version provided in Section 3.1. Please refer to [5] for the full description. 

The square-root solution uses storage space of size n + 2-y/n at the data repository. (See Figure 1(a).) 
This space is split into a buffer, B, and a table, T. The buffer B has size yjn and is used to cache the last 
y/n requests. Table T contains a pseudo-random permutation of the n data items and yfn dummy items. 

Each data item is associated with a key (virtual RAM address) x, x = 1, • • • , n and each dummy item 
is given a key n + d where d = 1, • • • , y/n. All items in T are ordered according to a pseudo-random 
permutation function vr such that tt{x) gives the location of the item with key x in T. (The full solution, 
which uses a binary search, is omitted in our description since the overall complexity of the request is 
0{y/n).) The square-root ORAM simulation method is outlined in Algorithm 1. Note that table T has to be 
rebuilt after every y/n requests. The rebuild phase consists of obliviously replacing the items in T for which 
there is a new instance in B, associating the keys of real and dummy items with tags from a new permutation 



Algorithm 1 Oblivious RAM simulation using the square-root approach [5]. 
Generate pseudo-random permutation function vr 

Initialize table T by storing the n data items and y/n dummy items according to permutation tt 
count •(— 1 

while true do {process a request} 
found ^ false 

Scan all the locations in buffer B. During the scan, if data item x is found, set found ^ true. 
if found then 

Access location 7r(n + count) in T {a dummy item} 
else 

Access location 7r(x) in T {data item x} 
end if 

Rewrite B, adding or replacing data item x 
count ^ count + 1 
if count > y/n then 

Generate pseudo-random permutation function n' 
Construct a new table T' with n' using items in T and B. 
clear B and set T <— T' , ir <^ tt' , and count <r- 1 
end if 
end while 



it', and sorting items in T according to vr'. The rebuild phase takes 0{n log^ n) accesses. Since the rebuild 
happens only once every ^/n requests, the amortized access overhead per request is 0(v^log^ n): 0{^/n) 
accesses for the request phase and 0(v^log^ n) accesses for the rebuild phase. 

Obliviousness: Requests are handled by scanning buffer B and accessing T. Due to the scheduled 
rebuilds, data items are associated with new tags every ^/n requests. Between the rebuilds, unique locations 
are accessed in T: either an item x is not present in the buffer and hence a unique location, 7r(x), is accessed, 
or a unique dummy item, 7r(n + count), is accessed. 

2.2 log n Hierarchical Solution 

We now describe the efficient oblivious RAM simulation by Goodrich et al. [7]. This method has O(logn) 
amortized access overhead, 0{n) space overhead at the repository, and client memory of size 0{ny), where 
V is an arbitrary positive constant. This method is stateless and thus suitable for a multi-user scenario since 
no client keeps a state between requests. 

2.2.1 Cuckoo Hash Table 

Since the method of [7] uses cuckoo hash tables, we give a short description of a cuckoo hash table. (See [1 1] 
for more details.). 

A cuckoo hash table for n items consists of two hash tables, Ti and T2 with two hash functions, hi and 
/i2. Each hash table contains m = (1 + e)n memory cells, with e a (small) positive constant. An item with 
key X is found either in location hi{x) in Ti or in /i2(x) in T2. We say that a failure occurs when there are 
only two possible locations for three keys x, y, z, i.e. hi{x) = hi{y) = hi{z) and h2{x) = /i2(y) = h2{z). 
In this case a stash, S, of constant size is used to keep items that did not find a place in tables Ti and T2. The 
retrieval of an item now includes a scan of S, which takes 0(1) time. Kirsch et al. [8] show that a cuckoo 
hash table with a stash of size s overflows with probability 0(l/n*+^). 

Recently Goodrich and Mitzenmacher [6] showed that one can construct a cuckoo hash table of size n 
with a stash of size s obliviously using 0{n + s) accesses to the data repository and assuming access to 
private workspace of size 0{n'^). 

2.2.2 Oblivious Simulation 

We are now ready to describe the oblivious RAM simulation by Goodrich et. al. [7] . The memory at the 
data repository consists of a cache C for q data items, cuckoo hash tables Ti, • • • ,Tl and a stash S. (See 
Figure 2(a).) The size of the cache, q, is O(logn) and stash S has also size O(logn). Each table Tj has 
size 2*g and L is the first integer i such that \Tl\ > n, hence L is O(logn). Each cuckoo hash table Tj is 
initialized with two hash functions, h\ and h\. Stash S is shared between all L tables and is large enough to 
avoid overflows in tables Ti, T2, • • • ,Tl with high probability [7]. 

On a request for item x, the client executes Algorithm 2. After q requests cache C becomes full and we 
obliviously move elements from C to Ti. The move consists of creating a new cuckoo hash table Ti from 
the elements in C. The next time C becomes full, instead of moving C to Ti, we move the items from C and 
Ti to T2. Similarly, when we are about to move items to Tj for the second time, instead we move all items 
from C, Ti, . . . Tj_i to the first empty table among Ti through Tl. Oblivious construction of cuckoo hash 
table Ti takes 0(|Tj|) accesses to the data repository. Since table Tj is rebuilt every 0(|Tj|) requests and 
eventually every request causes O(logn) tables to be rebuilt, the amortized overhead is O(logn) accesses 
per request. 

Obliviousness: Scans and writes to cache C and stash S are oblivious since it is done sequentially. 

Table Tj is accessed either according to a pseudo-random hash function or in random locations because 
item X is found in an earlier level of the construction. Cache C and tables Tj , j < i are empty when Tj 



Algorithm 2 The request phase during oblivious RAM simulation with the logn hierarchical approach [7]. 
found ^ false 

scan cache C and stash S. if x is found in one of them set found ^ true 
for each level i, I < i < L do 

if found is true access random locations in Tj. 

else access locations h\{x) and /i^la;) in Tj. 

if X is found set found ^ true 
end for 

Remove x from S* if x was found in S. Rewrite S. 
Rewrite C, adding or replacing data item x. 

is rebuilt and hence are used to cache items found in Tj. Since Tj is emptied and initialized with two new 
pseudo-random hash functions as soon as levels above it become full, it is never accessed twice for the same 
item. Hence, from the point of view of the adversary. Bob, accesses to Ti look random. 

3 De-amortized ORAM Simulation 
3.1 The Square Root Solution 

In this section, we present an oblivious RAM simulation method with 0{y/nlog^ n) access overhead in 
the worst case. This method is based on the square-root approach originally proposed in [5], which has 
O(nlog^n) worst-case access overhead and 0{^/nlog^ n) amortized access overhead (see Section 2.1). 
We present first the simple square -root solution, to demonstrate some of the ideas behind the more efficient 
technique developed in Section 3.2. Note that only recently an oblivious RAM solution with sublinear 
worst-case access overhead has been proposed [12]. 

Intuition: The most expensive step of the square-root approach is building a new table, where items 
and dummy values are ordered using a new pseudo-random permutation. This step is executed every ^/n 
requests and takes 0(n log^ n) accesses. Our idea is to split the accesses for the rebuild into ^/n batches, 
each with 0(v^log^ n) accesses, and to execute each batch after processing a request so that the new table 
is ready to be used after processing ^/n requests. We will show how this idea can be implemented while 
preserving obliviousness and keeping the same asymptotic access overhead and storage overhead as the 
original method. 

Memory Layout: We organize the memory on the data repository into five areas. We make use of 
two buffers, Bcm and i?prcv» each of size ^/n. We also have two tables, Tcur and Tncxt» each of size 
n + ^/n. These tables are built using different pseudo-random permutations on the n data items outsourced 
by the client and ^/n dummy values. Finally, we employ a workspace W of size n + 2^/n for constructing 
incrementally the new table, Tncxt. while the current table, Tcur, and the two buffers, Bcur and i^picv, are 
being used to process requests. (See Figure 1(b) for illustration.) 

InitiaUzation: We split a sequence of requests into epochs, where an epoch consists of exactly ^/n 
requests. Initially, buffers i^cur and i^prcv are empty and each of the tables Tcur and Tncxt contains the 
n items and y/n dummy items permuted according to a pseudo-random permutation, where Tcur uses 
permutation ttq and Tncxt uses permutation vri. 

Processing an Epoch: During an epoch, buffer i?cur caches the y/n items being requested in the current 
epoch while buffer -Bprcv caches the ^/n items that were requested in the previous epoch. Thus, i?prcv is 
empty during the first epoch. Also, during an epoch, table Tcur is used for processing requests and workspace 
W is used to build incrementally a new table, based on a new pseudo-random permutation. 



Algorithm 3 Oblivious RAM simulation with our de-amortized version of the square-root approach. 
Generate pseudo-random permutation function TTcur 

Initialize table Tcur by storing the n data items and ^/n dummy items according to permutation vTcur 
Initialize W with n data items and ^/n dummy items 
while true do {process the requests in an epoch} 
Generate pseudo-random permutation function vTncxt 
request^count ^ 1 

while true do {process request for data item x} 
found ^ false 

Scan all the locations in buffers Bcm and Sprcv- During the scan, if data item x is found, set 
found ^ true. 
if found then 

Access location 7rcur(^ + request -count) in Tcur {containing a dummy item} 
else 

Access location 7rcur(a^) in Tcur {containing data item x} 
end if 

Rewrite i?cur» adding or replacing data item x 
Execute the next batch of c^/n log^ n accesses to workspace W to construct table Tncxt using 



permutation vTncxt 

request ^count ^ request -COunt + 1 

if request _count > y/n then 
break {end of the epoch} 

end if 
end while 
Copy the new table from W to Tncxt 

Copy Bcni to Bprcv 

Copy Tcur and i?cur to W 
Empty Bcur 

Copy Tncxt to Tcur 
^cur ^ '^ncxt 

end while 



Transitioning to the Next Epoch: At the end of an epoch, the new table is copied from W to Tncxt- 
Next, table Tcur and buffer i?cur are copied to W. Finally, table Tncxt is copied to Tcur to accommodate the 
requests from the next epoch. Also, we overwrite Bp^cv with items from Bcur and we empty i^cur- 

Incremental Table Construction: The construction of the new table, Tncxt in workspace W takes as 
input Tcur and i^cur from the previous epoch. We say that the instance of a data item in Tcur is stale if there 
is an instance of the same data item in i^cur- Using an algorithm from [5], we obliviously filter out the 
stale instances of the data items and we construct a table for the set consisting of the n data items and ^/n 
dummy items, storing them according to newly generated pseudo-random permutation. Since this algorithm 
performs 0{n log^ n) accesses to the data repository, we de-amortize it by splitting its sequence of accesses 
to workspace W into ^/n batches of cy^log^ n accesses each, for some constant c > 0. The construction 
of table Tncxt starts at the beginning of the epoch and a batch of accesses is executed after processing each 
request. Hence, the new table Tncxt is ready by the end of the epoch. 

Our oblivious RAM simulation algorithm based on the square -root approach is outlined in Algorithm 3 
and its properties are summarized in Theorem 1. 



Theorem 1. Our oblivious RAM simulation method based on the square-root approach has 0{y/n\og n) 
worst-case access overhead per request, 0{y/n) space overhead at the data repository, and 0(1) client 
memory, where n is the number of data items. 

Proof. (Sketch) The worst-case access overhead of each request is 0{^/n\o^ n) since we scan two 
buffers of size y/n, access one table entry, and execute O(y^log^n) accesses to perform one batch of 
the table rebuild. Also, 0{n) additional space is used at the server. 

We now consider the obliviousness of our method. During each epoch, unique items are accessed in 
table Tcur- Namely, if the requested data item is not found in the buffer, we access it in Tcur, else we 
access a new dummy item in Tcur- Moreover, in the beginning of each epoch Tcur is initialized with a new 
permutation over n items and y/n dummy values. 

The method is correct since the user is always returned the most up-to-date instance of the requested 
item: if the requested data item was last requested in the current epoch then it is found in Bcur, else if it was 
last requested in the previous epoch, it is found in i3prcv» else Tcur has the latest instance. D 

Read/Write Data Repository: In Algorithm 3 we made an assumption that data repository allows us 
to manage outsourced memory using copy operator. However, it is not required for execution of our de- 
amortized method and achieving the same worst case overhead of O(v^log^n). We provide only an 
intuition behind this approach. If the data repository supports only read and write operations one can 
alternate blocks of memory used for rebuild and for handling requests between the epochs, e.g. during 
even numbered epochs Bcav is used to cache current requests while during odd epochs it serves as a buffer 
of requests from the previous epoch. 

3.2 The log n Hierarchical Solution 

We now describe the de-amortization of the oblivious RAM simulation method presented in [7], which is 
based on a hierarchical memory layout at the server and has O(logn) amortized access overhead. The 
intuition behind the de-amortized version of this method is similar to the one we used in the square-root 
solution (see Section 3.1): we incrementally rebuild tables while handling requests using previous versions 
of tables and buffers. Requests are handled using two sets of buffers: one for items requested in the current 
epoch and the other for items requested in the previous epoch. However, recall that the construction of [7] 
has O(logn) buffers implemented as cuckoo hash tables. This complicates our task since now we need to 
have a copy of each cuckoo hash table. Also due to the dynamic arrangement of the buffers, one buffer spills 
into the next one and so on, we eventually need to construct 0(log n) cuckoo hash tables during each epoch. 

Memory Layout: Our memory layout at the data repository is schematically illustrated in Figure 2(b). 
Extending the oblivious RAM data structure of [7] (see Section 2.2), we employ two caches, Ccur and Cprcv, 
of size q = O(logn), one stash, S, of size O(logn), and 2L — 1 cuckoo hash tables Ti, T{, T2, T2, . . . , 
Tl^i,T'^_^,Tl where each Tj and T/ has size 2^q and L is the smallest i such that 2*g > n. We also keep a 
workspace W for rebuilding cuckoo hash tables. The workspace stores the last 2^q requested items in a list, 
D. In addition, it contains L work areas for rebuilding cuckoo tables. The i-th work area consists of storage 
space T^ , of size 0(2*g), for a cuckoo hash table at level i and of overflow space S^ , of size 0(log n), for 
the corresponding stash. 

Initialization: We build Tl as a cuckoo hash table for the n data items and put into stash S any items 
that did not fit. Both caches Ccur and Cprcv and other tables Tj and T/ (for i < L) are empty. 

Processing an Epoch: In this section an epoch is defined as a sequence of q requests. During an epoch, 
cache Ccur stores data items last requested in the current epoch and cache Cprcv stores data items last 
requested in the previous epoch. Thus, these caches play roles similar to those of buffers Bcur and Bprev in 
Section 3.1. Each request is processed by scanning caches Ccur and Cprcv » scanning stash S, and accessing 
locations in tables Ti, T{, T2, T2, . . ., T^-i, T'^_i, Tl. In addition, a batch of accesses is made to workspace 
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Figure 2: Memory layout of the data repository during oblivious RAM simulation: (a) original version of 

the logn hierarchical solution [7]; (b) our de-amortized version (Section 3.2). 

W toward rebuilding its cuckoo tables. The incremental rebuilding process guarantees the completion of a 
cuckoo table in T^^ and its stash in Sj^ after 2*^^ epochs. 

Incremental Construction of L Cuckoo Hash Tables: Recall that a cuckoo hash table Tj of size 2*q 
can be constructed obliviously using 2^q accesses to the data repository and 0{n'^) private memory [6]. To 
help us explain the concurrent oblivious rebuild of L cuckoo hash tables, we introduce a data structure / 
that stores the set of indices of the cuckoo tables that need to be rebuilt in workspace W. Note that Queue 
depends only on the number of requests made so far hence it can be computed in constant time. / starts 
empty. After every 2*^^ epochs index i is added to /. When an index i is added to / a sequence of 2*6g 
accesses is required for a rebuild of T^ , for some constant 6 > 0. After each request, the client executes 26 
accesses for each index in / so that the construction of table T^ is completed in 2*~^ epochs. Observe that 
after the first 2*^^, epochs index i is always present in /. Moreover, after 2^^^ epochs indices 1, 2, . . . , L 
are present in / and / does not change from then on. This also means that eventually all L tables are being 
rebuilt during an epoch. (See Figure 3 for an illustration of the rebuilding process.) To accommodate L 
concurrent rebuilds, we increase the requirement on the size of client's private memory from 0{ny) in [7] 
to 0{ii7'), for some fixed constants t > v and z^ > 0. 

Transitioning to the Next Epoch: We append items in Ccur to D, the list in workspace W that keeps 
track of the 2^q previously requested items. We then copy Ccur to Cprcv and empty it. Hence Ccur can be 
used to cache requests during the next epoch. We then check which tables are finished, i.e. T^^ is finished 
if the current number of epochs is a multiple of 2*~^ since T^^ takes 2*^^ epochs for a rebuild. Each such 
table T^ is then copied to either Tj or T/. If Tj and T- are both empty or both full T^ is copied to Tj, stash 
Sf^ is merged with S and T/ is cleared. If only Tj is full T^ is copied to T/, stash 5,^ is merged with S. If 
Tl, the table from the last level, is finished we clear first 2^q items from D since all these items are now in 
Tl and no table from earlier levels requires them for a rebuild. 
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Figure 3: Sequence of accesses during oblivious RAM simulation: (a) original version of the logn 
hierarchical solution [7]; (b) our de-amortized version (Section 3.2). The size of the cache is denoted by q, 
which is O(logn). 

Stash Size: Goodrich et al. [7] show that a single stash of size 0(log n) is enough to avoid overflows in 
cuckoo hash tables Ti, . . .,Tl where Tj contains 2*g items. In our construction, we use a single stash S for 
two collections of cuckoo hash tables. A single stash ensures that if item x happened to not fit into two tables 
Ti and T' then only the most recent copy is present in S. One can view stash S* as a joint stash between 
tables Tl, . . . ,Tl and T{, . . . , T'^_^. Suppose a stash of size s log n is used in the construction of [7], where 
s > 1 is a constant. Then we set our stash S to be of size 2s log n, where the first s log n locations are used 
for tables Ti, . . . ,Tl and the remaining slogn locations for r{, . . . ,T'^_^, with the additional constraint 
that only unique items can be present in S. The latter constraint is enforced when we merge stash Sj^ of a 
new table T^ with S. 

Our oblivious RAM simulation algorithm based on the log n hierarchical approach is outlined in Algo- 
rithm 4 and its properties are summarized in Theorem 2. 

Theorem 2. Our oblivious RAM simulation method based on the log n hierarchical approach has 0(log n) 
worst-case access overhead per request, 0{n) space overhead at the data repository, and 0{tt7') client 
memory, where n is the number of data items and r is any fixed positive constant. 

Proof. (Sketch) We first show that handling of each request using the above protocol takes O(logn) 
accesses. Retrieving a data item takes O(logn) accesses since three blocks of size O(logn) are scanned 
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Algorithm 4 Oblivious RAM simulation with our de-amortized version of the log n hierarchical approach. 
Initialize Tl and S with a cuckoo hash table with a stash using n data items. 
I -^ {}, request _count ^ 
while true do 

while true do {on request x} 
found ^ false 

Scan all the locations in caches Ccur and Cprcv and stash S. During the scan, if data item x is 
found, found ^ true. 
for each level i, I < i < L do 
if j / L and T/ is not empty 
if found is true access random locations in T/. 
else access locations h\ (x) and /i2 (x) in T/. 
if X is found, found ^ true. 
if Ti is not empty 
if found is true access random locations in Tj. 
else access locations h\{x) and /i^l^;) in Tj. 
if X is found, found •(— true. 
end for 

Rewrite Ccur, adding or replacing data item x. 
if X is found in stash S remove x from S. Rewrite S. 
for i € I 

Make next 26 accesses towards a rebuild of table T^ 
request _count ^ request .count + 1 
if request _count mod g = then 
{end of the epoch} 

Copy Ccur to Cprev and append it to D. 
Empty Ccur- 

for i G sorted-decr _order{I) 
if request-Count mod 2^~^q = 
ifi = L 

copy T^ to Ti. 
else if Ti and T/ are both full or both empty 

Empty TI and copy T^ to Tj. 
else 

copy T^ to T/. 
Merge 5^" and S. 
for each level i, 1 < i < L 
if request_count mod 2*~^g = 

Copy last 2*"^Q' items from D to T-'^ 
ifi 0/ 

/^/U{i}. 
ifi = L 
empty D. 
end if 
end while 
end while 
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and two accesses are made to 2L tables, where L is O(logn). The batch of accesses for table rebuilding 
made after each request consists of 26 accesses for every table in /, where / has at most L indices and b is 
a constant. The method clearly requires only 0{n) space on the data repository. For every rebuild, we use 
the method of [6] which requires 0{n'^), i/ > 0, of client private memory. Since our method concurrently 
makes O(logn) rebuilds 0{n^) of private memory is required for t > u. 

We now consider the obliviousness of the method. Table rebuilds remain oblivious since they follow a 
predetermined schedule that depends on n and request _count and are performed in the same way as in the 
original ORAM construction in [7]. 

It remains to show that each request remains oblivious. Accesses to the caches, Ccur and Cprcv» and 
the stash, S, are oblivious since their memory locations are scanned (read and rewritten entirely) for each 
request. Since accesses to table Tj depend on whether an item is found in T[ we first show the obliviousness 
of access sequence to T/. Observe that when T/ is substituted with a new cuckoo hash table Tf^ cache Ccur 
and all tables T'^j are empty. Since each table on level i can store up to 2*~^g items before it is emptied 
there is space to remember the following number of requests: 

'? + E}=l2^-ig = 2-ig. 

If an item is not found in previous levels, it is accessed according to pseudo-random hash functions h\ 
and /12 ■ Otherwise, T/ is accessed in random locations. T[ is cleared as soon as next table for this level, i.e. 
next T^ , is ready. This happens 2*~^g requests after T/ was last substituted with a new table. Hence, T/ is 
never accessed more than once for the same item. 

An access to table Tj follows an access to T/ and is random if an item is found in earlier tables or in T[. 
Note that similarly to T/ cache Ccur and all tables T'^^ are empty when Tj is ready. Moreover T'^ is empty 
as well. Hence, there is space to remember the following number of requests: 

However, Tj is replaced with a new table every 2*g requests. Hence, no location is accessed more than 
once in table Tj as well. 

To prove the correctness of the method, we observe that the most current copies of the data items are 
present in the caches or smaller tables. Moreover, table T[ contains more recent requests than Tj and stash S 
contains any items that did not fit in their corresponding tables. When newly constructed tables are moved 
from W to the memory for handling requests, we merge the stash of larger tables with S first. In this case, 
if the same item did not fit into more than one table, only the most recent copy is in S. Since we first scan 
the caches, the stash and start accessing tables from smaller levels, with T/ before Tj, our method returns to 
the user the latest instance of the requested item. D 

Read/Write Data Repository: Similar to de-amortized version of square root solution from Section 3.1 
we can relax the assumption of the interface that data repository provides us. If read and write are the only 
supported operations we can alternate the blocks of memory used for rebuilds and for handling the requests 
depending on the epoch count. 

4 Conclusion 

We have presented methods for oblivious RAM simulation with efficient worst-case access overhead. Our 
methods are based on de-amortizing two known solutions, the square root approach and the log n hierar- 
chical approach, which have efficient amortized access overhead but $7(n) access overhead in the worst 
case. For each of our methods, the worst-case access overhead per request is asymptotically equal to the 
amortized access overhead of the solution it is based on. In particular, our log n hierarchical solution incurs 
log n access overhead on every request. 
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